Android for the Enterprise

Blake Meike

Developer, Architect, Android Evangelist

• Author of Programming Android published by O’Reilly.
• Speaker at StrangeLoop, OSCON, AnDevCon.

blake.meike@gmail.com

twitter: @callmeike

blog: http://portabledroid.wordpress.com/

… and who are YOU?

I think you’ll get the most out of this if:

• You are very familiar with Java.
• You have built at least one Android app.
• You have some experience with Web Services.

Enterprise Android: It’s time!

These are just a few of the hundreds of articles that turn up in response to a query for "enterprise mobile"

• Feb. 22, 2012, Symantec Corp, State of Mobility Survey: "a global tipping point in mobility adoption. … 71 percent of enterprises at least discussing deploying custom mobile applications and one-third currently implementing or have already implemented custom mobile applications."
• ibid: "Despite this adoption, almost half (48 percent) of survey respondents mentioned that mobility is somewhat to extremely challenging and a further 41 percent of survey respondents identified mobile devices as one of their top three IT risks."
• Feb 13, 2012, Sandhill Group, Leaders in Mobility Strategies: Tug of War Between Business Risk and Value: "In Wave 1 enterprises focused on making common internal productivity applications available for mobile users. Personal Information Management (PIM) including email, calendar, and contacts became the “killer” applications driven mainly by the BlackBerry universe. Much of the enterprise world is still in this wave but moving rapidly forward to the next wave."
• ibid: "The iPhone, iPad, and the Google Android devices ushered in Wave 2. Enterprises realized that they can reach their customers (particularly in the B2C world) by developing user-friendly and rich applications."

It’s making people nervous…

The usually cited risks are:

• Business decentralization
• Increased load on IT infrastructure
• Let’s not even talk about security…

An issue of style

As developers, I think we face one more issue:

Web service developers and mobile developers have different understandings of what the environment looks like.

   Things web service devs take for granted

• An incredibly rich set of open-source frameworks
• RDBMS and ORM
• Unit testing
• Optimization means 100% CPU usage

   Things mobile devs take for granted

• Networks are unreliable
• The OS is unreliable
• The hardware is unreliable

   Common ground

Actually, an Android application looks a lot like a web application:

• An Activity is a Servlet
• Developers must deal with the life-cycles of managed objects in both environments
• Concurrency is in your face in both environments
• Testing is painful in both environments

The Android Way

I’d like to talk in some detail about a couple of practices that may seem wrong at first, to one camp or the other (possibly to both).

Embrace them, though, and you will create better, simpler, and more reliable Enterprise Applications

• Embrace Cursors
• Embrace “Dobjanschi” Architecture
• Embrace ContentProviders

Embracing Cursors

When a Web Service Developer has to deal with a database, the tool of choice is very likely to be some kind of Object-Relational Mapping framework:

• Hibernate
• IBATIS
• many more…

Android ORM frameworks do exist:

• OrmLite
• stORM

They might even be a good idea, in some applications…

In Android, forget ORM: Just use Cursors

   The Case for Cursors

• For:
  • Occam’s Razon - Cursors are straightforward, clear, and fast.
  • CursorLoader - A CursorLoader is an incredibly simple way to get data into your Activity
  • ListView - Puts a Cursor right up against the glass
  • ContentObservers - Registering a cursor for changes in the dataset that underlies it, is simple.
  • IPC - Cursors work across process/application boundaries
• Against:
  • Mutable Row-pointer - Need a protocol for managing currently visible row
  • Not thread safe - Can’t be passed between threads wo/synchronization

   Wrapping the Cursor

One possibility: a lightweight bean-like accessor.

• Restrict access to the row pointer
• Getter semantics

Very simple!

• Doesn’t handle →* relationships
• Still not thread safe

   POJO-like access to a Cursor: Example

public class EACursorAccess extends CursorAccess {
    public EACursorAccess(Cursor c) {
        super(c,
            EAContract.Columns.ID,
            EAContract.Columns.COL1,
            // other columns...
            EAContract.Columns.COLN);
    }

    public int getId() {
        return getCursor().getInt(getColIdx(EAContract.Columns.ID));
    }

    public String getCol1() {
        return getCursor().getString(getColIdx(EAContract.Columns.COL1));
    }

    // Other getters...

    public String getColN() {
        return getCursor().getString(getColIdx(EAContract.Columns.COLN));
    }
}

   POJO-like access to a Cursor: Use

ValuesCursorAccess pojo = new ValuesCursorAccess(cursor);
while (cursor.moveToNext()) {
    // most pojo operations are safe here...
    processPOJO(pojo);
}

   POJO-like access to a Cursor: Base Class

public abstract class CursorAccess {
    private final Cursor cursor;
    private final Map<String, Integer> colMap;

    public CursorAccess(Cursor c, String... cols) {
        cursor = c;
        Map<String, Integer> m = new HashMap<String, Integer>();
        for (String col: cols) {
            int idx = c.getColumnIndex(col);
            if (0 <= idx) { m.put(col, Integer.valueOf(idx)); }
        }
        colMap = Collections.unmodifiableMap(m);
    }

    protected final Cursor getCursor() { return cursor; }

    protected final int getColIdx(String col) {
        Integer idx = colMap.get(col);
        if (null == idx) {
            throw new IllegalArgumentException(
                "Cursor does not contain column: " + col);
        }
        return idx.intValue();
    }
 }

   Embracing Cursors

Instead of abstracting cursors away in Android,
use them, pervasively, as a standard abstraction for data

Next up: Networks are data…

Embracing “Dobjanschi” Architecture

If you are embarking on a connected application, you absolutely should view Virgil Dobjanschi’s 2010 Google I/O talk:

http://www.youtube.com/watch?v=xHXn3Kg2IQE

The architecture he proposes probably seems excessively complex…

In Android, a network connection should be fronted by a ContentProvider

   “Dobjanschi” Architecture

The “Figure Eight”:

• The UI talks only to a local cache
• A service synchronizes the cache with the network.

   Outbound processing

• The user changes environment state
• The Activity handles the state change by calling the ServiceHelper
• The ServiceHelper converts the method call into an Intent and sends it to the Service (async return value via callback)
• The Service is the context in which the lower half of the “figure eight” runs
• The Processor changes the state of a row in the ContentProvider: marks it “dirty”. It also initiates REST call to synchronize it.
• The RESTMethod converts the Processor call to network REST, sends it, and awaits the reply

   Inbound processing

• The network data changes state (response, GCM, poll)
• The RESTMethod calls the Processor with the state change
• The Processor updates the ContentProvider
• If content changed the Content Provider notifies any ContentObservers

   The Case for “Dobjanschi” Architecture

• For:
  • The Activity dramatically simpler: No AsyncTasks
  • Possible to represent exact state in UI
  • Architecture can be abstracted as a framework
• Against
  • The ContentProvider can be complex
  • The Processor will be complex

   The Activity

Losing AsyncTasks is a major win. They are a constant headache!

• Long running operations (timeouts, etc)
• Handling failures
• Lifecycle Management

   The ServiceHelper (call)

Although it is, architecturally, a separate component, it is really quite simple.

Possible implementations include:

• AIDL/Bound Service
• Broadcast intent
• Pending Intent

Here’s a simple implementation using a PendingIntent:

public void doSomething(Activity ctxt, String arg1, String argn) {
    Intent intent = new Intent(ctxt, EnterpriseService.class);
    intent.putExtra(EnterpriseService.ARG1, arg1);
    // add other args...
    intent.putExtra(EnterpriseService.ARGN, argn);
    intent.putExtra(
        EnterpriseService.CALLBACK,
        ctxt.createPendingResult(
            REQ_ID,
            new Intent(), // empty default response
            PendingIntent.FLAG_ONE_SHOT));
    ctxt.startService(intent);
}

   The Service

protected void onHandleIntent(Intent intent) {
    Intent resp = new Intent();
    resp.putExtra(
        RESULT,
        doSomething(
            intent.getExtras().getString(ARG1),
            // other args...
            // intent.getParcelableExtra(...)
            intent.getExtras().getString(ARGN)));

    try {
        ((PendingIntent) intent.getParcelableExtra(CALLBACK))
            .send(this, Activity.RESULT_OK, resp);
    }
    catch (CanceledException e) { Log.w(TAG, "Cancelled!", e); }
}

   ServiceHelper (response)

Called from Activity.onActivityResult:

public boolean onDoSomethingResult(
    int reqCode,
    int resCode,
    Intent resp,
    MessageHandler hdlr)
{
    if (REQ_ID != reqCode) { return false; }

    if (Activity.RESULT_OK != resCode) { hdlr.onFail(resCode); }
    else {
        hdlr.onMessage(resp.getExtras().getString(EnterpriseService.RESULT));
    }

    return true;
}

   Processor

The Processor is probably the most complex Component. This is complexity that used to be distributed across your AsyncTasks.

• Manage concurrency
• Use transactions liberally.
• Cache management is generic. DB cache rows have three states:
  • Dirty - Record state has been changed on this device
  • Pending - There is an outstanding request to sync this record
  • Synched - Record is apparently in sync with external store. What it means to be in sync will depend on business logic.

   The RESTMethod

• The RESTMethod translates in and outbound requests to your RESTful protocol.
• Consider using a SyncAdapter.
• Note:

Apache HTTP client has fewer bugs in Android 2.2 (Froyo) and earlier releases. For Android 2.3 (Gingerbread) and later, HttpURLConnection is the best choice.

   Embracing “Dobjanschi” Architecture

AsyncTasks hide state transitions in ephemeral objects.
Just don’t use them for network transactions.

• It isn’t as complicated as it sounds.
• It isn’t any more complicated than it needs to be!
• There is every possibility that this architecture will become a framework

Next up: The right place to record state transitions

Embracing the Content Provider

When a Web Service Developer has to deal with a database they probably think DAO.

The Android Documentation even states that, “unless you intend to share your data, you may not need a ContentProvider”

In Android, a ContentProvider is the DAO. Just use it.

   The Case for Content Providers

• For:
  • All of the arguments for Cursors apply
  • CursorLoader works better than AsyncTaskLoader
  • A ContentProvider allows publishing a view of your data to other apps
• Against
  • API is constrained
  • Batch operations are harder

I admit that this case is harder to make than the previous two.

   Using the QueryBuilder

The virtual tables that your Content Provider publishes should not be the real tables or real columns. The QueryBuilder supports this separation.

• Use the URI to determine the table
• Use ProjectionMap to map column names:
  • In strict mode throws exception on attempt to use unmappable column name
  • Naive mapping VirtualCol → ActualCol doesn’t work
    • SELECT _id, realCol FROM MyTable ORDER BY virtCol
  • Map: VirtualCol → ActualCol AS VirtualCol does!
    • SELECT rowid AS _id, realCol AS virtCol FROM MyTable ORDER BY virtCol

   ProjectionMap Example

Note that the EXTRA column is completely virtual…

private static final Map<String, String> COL_AS_MAP;
static {
        Map<String, String> m = new HashMap<String, String>();
        m.put(EAContract.Columns.ID,
                DbHelper.COL_ID + " AS " + EAContract.Columns.ID);
        m.put(EAContract.Columns.COL1,
                DbHelper.COL_A + " AS " + EAContract.Columns.COL1);
        m.put(EAContract.Columns.COLN,
                "CASE WHEN " + DbHelper.COL_Z
                        + " NOT NULL THEN " + DbHelper.COL_ID
                        + " ELSE NULL END AS " + EAContract.Columns.COLN);
        COL_AS_MAP = Collections.unmodifiableMap(m);
}

   ProjectionMap Example (cont…)

The Query method gets really (safe and) simple.

private Cursor doQuery(
        String[] proj,
        String sel,
        String[] selArgs,
        String ord,
        long pk)
{
        SQLiteQueryBuilder qb = new SQLiteQueryBuilder();
        qb.setStrict(true);

        qb.setProjectionMap(COL_AS_MAP);

        qb.setTables(DbHelper.TABLE);

        if (0 <= pk) { qb.appendWhere(PK_CONSTRAINT + pk); }

        return qb.query(
                helper.getWritableDatabase(),
                proj,
                sel,
                selArgs,
                null,
                null,
                ord);
}

   Embracing Content Providers

Android thinks of data in terms of Content Providers
If you think that way too, your life will be easier

Building Enterprise Apps for Android

What would I like you to take away from this?

• At a high level:
  • Be prepared to convince others to try something new
  • Be prepared to try something new yourself!
  • Don’t fear the cursor
  • Avoid AsyncTasks
• Some low level techniques:
  • Wrapping a Cursor for safer access
  • Use a PendingIntent for Service → Activity callback
  • Use the QueryBuilder to map table virtual → real

Slides and code at:

https://github.com/bmeike/AnDevConIV.git